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Abstract 

To thoroughly test the on-board software for the MSTI 2 spacecraft, it was necessary to generate an envi- 
ronment for the software which accurately simulated the on-orbit conditions of the spacecraft. To achieve 
this, the MSTI 2 Processor-1 n-the-Loop (PIL) high-fidelity simulator was developed. The entire development 
was completed in 3 months, and required 4 man-months of effort. This paper describes the design and 
development of this simulator, and the methodology employed. 


Introduction 


Thorough testing of the MSTI 2 on-board software required that the software be placed in an environment 
which accurately reproduces the conditions which the software will encounter while it is on orbit. This was 
achieved by using a flight processor with flight I/O boards, in conjunction with an AC-100 real-time simulator 
(see Figure 1). The unmodified on-board software was loaded onto the flight processor, and the I/O boards 
were utilized in their flight configuration. The AC-1 00 captured the output signals from the I/O boards, 
updated its simulation accordingly, and emitted the input signals to the flight processor. This process 
occurred in real time. 



Figure 1 


This paper discusses the design of the PIL, including an architectural overview, and the development of the 
PIL, including the methodology which was employed for rapid development. This paper focuses on the 
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real-time simulator, running on the AC-100, which emulated the on-orbit environment. The flight processor 
and the on-board software are not discussed in detail in this paper. 


Overview 


The MSTI 2 PIL provided a real-time simulation of the spacecraft environment for testing the on-board 
software running real-time on the flight processor (see Figure 2). The primary task of the MSTI 2 on-board 
software was attitude control, so the PIL was limited primarily to those functions relating tp the Attitude 
Control System (ACS). The subsystems which were emulated by the AC-100 include attitude dynamics, 
ACS sensors and actuators, and orbit dynamics. 


PIL Architecture 



• Displays simulation outputs 

• Controls simulation 


• Runs rsal-tlma spacecraft 
simulation 

• Accepts actuation commands 

• Outputs sensor measurements 


• Runs flight code 

• Computes actuator commands 
based on sensor readings 

• Outputs telemetry 

• Accepts ground commands 


Figure 2 


The PIL was designed to provide a realistic environment for the on-board software which accurately emu- 
lates the interactions between the processor and the rest of the spacecraft. The interfaces between the 
processor and the AC-1 00 were restricted to the ACS sensors and actuators, because these are the only 
ACS interfaces on the spacecraft available to the flight processor. The AC-100 intercepted those com- 
mands generated by the flight processor which were intended for the ACS actuators, and passed these 
commands to the spacecraft models. These models processed the commands, and the propagated 
dynamical subsystems, in order to generate realistic ACS sensor data. This data was passed along to the 
AC-100 output hardware, which emulated the electrical characteristics of the sensors. 

The simulator hardware includes the AC-1 00 off-the-shelf real-time simulator, the custom I/O boards for the 
AC-1 00, and the host workstation. The simulator software includes the development environment, the 
automatically generated software, and the handwritten C code. In addition, a dynamics analysis software 
program, AutoLev, was used to develop the attitude equations of motion and generate the attitude dynam- 
ics subroutines. 


The AC-100 System 

As indicated in Figure 2, the hardware in the PIL consists of the AC-100 real-time simulator, the host work- 
station, and the custom I/O electronics boards in the AC-1 00. The PIL software consists of the 
MatrixySystemBuild development environment, the automatically generated C code, the custom hardware 
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interface routines, and the C code reused from other projects. 

^^ a ^Tna^L n ^^Sy ¥ s?e1^ is an 
ewjronment wh,ch aHows the userto model systems with block diagrarre S 

directly from the block diagrams. The results of the simulations can^Tnafyzed ?n *^£ 01 . 

Rgure 3 4 ? how u s a block diagram from the earth sensor subsystem. The data flow is indi- 
^by the interconnections between the blocks, and the operations on the data are indicated bv the 

Earth Sensor Block Diagram 



IhlTfiS SSg^Ihe AC* oa user 10 build con,rol » anels <° P™'* 'Pal-lime interaction with 

tet«Jnon-rea| h t me hi^k H y ' dual subs ys/ems, orthe entire spacecraft model, could^e 

^ Be ?™e th ® b,ock diagrams could be simulated on the host workstation it was 

pSrtir^fhe 2^ A^IM ^° U{ ,0 deVe '° P S0Urce Cod ’ e ' and wi,hout 


simu- 
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dynamics models and sun ephemens were incorporated into the block diagram this way. 

Once the spacecraft block diagrams were developed ^agyms^ir^lyln^ex^utable 

SKSS o" no more «£n a tew min- 

utes. 

more difficult than editing the block diagrams. 

Other portions of the MSTI 2 PIL I/O J}1® , b^deveto^^ hard- 

^eM/O^lnes^hic^e^u^li^^^th^C^OO^ These custom routines were developed using the 
ordinary compile-link-debug cycle. 

as a User Code Block. 


Spacecraft Subsystem Models 

wal opening SSsffe' SESS 

=fe3S»S.tt“:ssss““ 

^^^.^r^eUnypt^TO^nai^chtasterthan^thi^^^^m^a^c^ms^nd^' faster than 
SbSSo^ seconds was modeled, and the 80 Hz. rate supported the. 


Si in Sensor 

The MSTI 2 sun sensor had a square of vitw, 

numbers representing the angular position of the sun i in i the Field « vwj ^^' n d was y enc0 ded in a data 
sun is present in the FOV and some hous ekeep.ng on an ordinary 

Sdau sueam’S RS- 422 voltage l«els. No commands were transmitted from the processor to the 

sun sensor. 

The error models included in the sun sensor model included geometric misalignment ol the sensor on the 
spacecraft, and a bias on each output angle. 
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SriafoutpSt of the AC-Too' d3,a S,ream were formatted in the SystemBuild models, and passed on to the 
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. QTTwtnrnn ECI to Vehicle 



Sun Sensor Block Diagram 
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Figure 4 




Earth Sensor 

The MSTI 2 earth sensor was a scanning horizon sensor with a 60° half-cone anale Due to the mechani- 
cal structure of the sensor, 81 0 of the scan cone were obstructed. 9 mecnam 

i 0f ,h * sens ° r included |H 0 angles, representing the phase and the chord of the earth in the 
nri^on??rf thlT c a ^i?l? n ' there Z ere ^ hrt ; e individual informational bits: one bit indicated the earth was 
^ e thTnh<:!n^n n o C ^?fh ®!»? 5 er - '"d'cated that the leading edge of the earth chord was blocked 
obstruction, and the third single bit indicated that the trailing edge of the earth chord was blocked bv 
me (Jistiudion. This information, afong with some housekeeping intonation, was encoded in a Salrame 

^I^m^1nn a R9^^uni!ano S iP er i Se< K? n ^ t0 the Pj; ocessor - This was transmitted on an ordinary serial data 
stream using RS-422 voltage levels. No commands were transmitted from the processor to the earth sen- 

S n u /®?shows the block diagram of the Earth Sensor model. This model used the output of the attitude 
SSh' along with the orbit dynamics model, to compute the sensor data. If the scan cone inter- 

amrmria?pKf rt K^hl e c^n r ^/f nd J?w ase *^f re com P u,e d. and the three bits described above, were set 
♦h P fKL y ’i ,he scan d,d n ? ,n | ersec t tne earth, the default values for the angles were used and 

delauhtalue and was^olt^aSle 6 b ankinQ blts ' The housekeeping information was hard-coded to its 
abfas'on SSffof theSngll oufptltf ' geome,ric misalignment of the sensor on the spacecraft, and 

seriafoiftput of the ACl ^ stream were form atted in the SystemBuild models, and passed on to the 
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Low Rate Gyro 

The primaiy source ol attitude rate infomiation on the MSTI 2 spacecraft was two high accuracy 2-axis 
gyros. However, they would saturate at a relatively low angular rate. 

There were a total of 32 conductors transmitting the gyro data. 

There was no housekeeping information transmitted from the gyros to the processor, and there were no 
commands transmitted from the processor to the gyros. 

The gyro models on the AC-1 00 used data only from the attitude^narrtcs models. The error models 
included geometric misalignment of the gyro on the spacecraft, and gyro biases. 

Because the gyros had to be emulated with very high precision and boari^ 

mmmm 

transmitted. 

Each GPC board could transmit all of the signals coming from one gyro, so 2 GPC boards were required in 
the PIL to emulate these gyros. 

KeS 

ing the next 80 Hz cycle. With this feedback scheme, the accumulated errors of the gyro emulators, 
compared to the desired values, never exceeded 8 arcseconds. 

Code Block. 


Hinh Rate Gvro 

The MSTI 2 spacecraft included one low fidelity 3-axis gyro which 
gyro, and there were no commands from the flight processor to this gyro. 

required about one half of a day to implement. 

Reaction Wheel Assembly 
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various housekeeping signals which the wheels could transmit to the processor. 

•sttsss sssssess ss srassfe a® sr ^xasssss, 

TTie net torque computed by the wheel model was passed along to the attitude dynamics model whirh 

SS^SWS Serafen *" SPaCeCraf '' The reac,ion wheel *“« 

s l re ^? witf ? high accuracy, the pulse stream generator from the gyro subsystem had 
already been developed, so it was easiest to simply reuse the gyro software and hardware with only 

a&na!r^S: BKM" the soft "! ar S- Ea?h GPC boai^l!^ two 

oHhe reatfioS w hells w«e ^"SSSed'Site HL*® *” RWAs ' 7,18 h « Jsekee P i "0 ^ outputs 


Thrusters 

thm«tanJifv 2 tl ? rusters: 8 low-force thrusters for attitude control and 4 high-force 

&«!£ for 0 ^ ^jus and orbit maintenance. These were simple on-off thrusters and could not be 

instead tho r!mSP?^ na c ? ntro1 ^he H'Qht processor issued no commands directly to the thrusters 
IS^and alow mKhSSft b l the P r ° cessor - A hi 9 h 111 level signal opened the 
the spacecraft proSlston syltem Va ' VeS ' There were ™ nv housekeeping signals to and from 

The fuel system on the MSTI 2 spacecraft regulated the pressure of the fuel being fed to the thrusters. 

~ T s o Sr , 

afthe e^ol McMhma U [Sse a ' lhe be9 ' nn “ 19 01 each ,hrusl P"' 3 ®. & a very short thrust (ail-off 

L ha n , ^n a L mode ' s in ,he MSTI 2 P,L were modeled with no thrust buildup or tail-off. The models simolv 
VK^aTthn Isterc 3 The wiTf nt on the speoecraft, based on the thrust capability and location of the indi- P V 
rosters. The forces were summed and passed along to the orort dynamics models and the 

hu r ^ Summ f^ a ^ P assed along to the attitude dynamics models. The propulsion models did not 
include blowdown of the fuel system, because this was a pressure regulated system 

'"orderto maintain sufficient fidelity of the attitude dynamics, it was decided that the thruster commands 

required by this simulation, but this high rate was no more difficult to implement than a lower rate. 6 

I h j a lu squired a short C interface routine, which was handwritten code. This routine did little more 

° al l the tow - eve 1/0 rout,nes su PP lied by the AC-100, and pass the results along to the I BSam 
This routine was implemented in the block diagram as a User Code Block 9 diagram. 

Attitude Dynamics Models 

The MSTI 2 spacecraft was modeled as four interacting rigid bodies: The main spacecraft structure and 
nwi™ ea f C fh° n w ^ e ?l s ' ^ he r P ain attitude dynamics block diagram is shown in Figure 5 The eauations of 
mo ^ of r hese -i b P dies were P eve l°ped using Kane's method, with the AutoLev software Dackaae Kane's 
KKrcS 0f intereSt 0n ,he bodies ' includin 9 non-conservative fric- 


337 


The moments and products of inertia of each body were set as parameters in the block diagram. 


tem and the actuator forces and (2) the angular accelerations of the bodies. 


Rotational Dynamics Block Diagram 


intent 

^ Omega 1 rad per sec l Q 

Omega 2 rad per secf 

\ 6 j — 


JL 

J 2 


<* 

SUPER 

3 

V 

block 



0.0125 



Time Step Size 


RWA £01 
Yl= 0.0W% RWA 


Y2= 0.0 
Y3= 0.0077 
Y4= 0.0 
Y5= 0.0077 
Y6= 0.0 




X RWA s 

u- - p 
(t RWA s 

It RWA p 
It RWA S 
It RWA p 


bmega2 dot rad per sec per sec_ 


pmega3 dot rad per sec per sec_ 


<3> 

-Q2i> 


\^-a> 


X RWA alpha rad per s per_s |-rr) 

Y RWA alpha rad per s per ^ . — pfy> 

2 RWA alpha rad per s per s fyp 


SC H01 , SC XX HOI Kg m2 
Yl* lfi.m'SC YY MOI Kg m2 
Y2= 19.633 ' 5C 22 MOI Kg m2 

8: 1 VtSigSS5g.S*i» 
8: o:88np » » ■Rip 


-G3> 


ix rwa spin axis X 
1 1 lO nx RWA spin axis Y 
RWA spin axis 2 
rfr RWA spin axis X 
m RWA spin axis Y 
ft RWA spin axis Z 
rfc RWA spin axis X 
rfc RWA spin axis Y 
rt rwa spin axis 2 


Figure 5 


accelerations of the individual wheels, 
to compute the spacecraft attitude. 


Orbit Dynamics Models and Sun Ephemeris 

These are two high fidelity mod els w h ;^ dfveKent, were rJSS'o 

&**■ — — - h ° ut 
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2 'Wl* 


further modification in the MSTI 2 PIL. 

Imiim'* nr | 0 ^®l includes a fifth order gravity model, and incorporates accelerations due to 

Sk tho ti!if ° pa9ator ? a fixed ' s, ep fourth-order Runga-Kutta integrator. The input to the sun eph€ 

thp S ^fii h |^^n^n P cr S i Sed as y 4 ea /’ m ? nth ’ da V- hour - m inute, secondhand millisecond, and the output is 
the sun location in ECI, accurate to a few arcseconds. ’ pui 15 

User Interface 

Whilethe PIL is executing, an interface was presented to the user which allowed the ooeratorto intorart 
AnVr!of simulation. This interface was built under Interactive Animation (IA) ^Jsina the Interactive 

fteBffid^gram^ 6 screens were built up 9 ra P h 'cally and connected to the various inputs and outputs of 


Interactive Animation User interface 
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Figure 6 


The main executive PIL screen is shown in Figure 6. From this screen, the user could invoke any one of 

thf n ^., d K e { lt t SCree ? f- at any i me - Wi,h ,hese screens - ,he UJ ? ar could monitor various internal variables in 
the PIL simulator real-time, or the user could interact with the simulation by varying parameters and adjust- 


339 












SSf&e to iWpSffSSdinates, or calk) inject any body rates «*> the gyro models, 
attitude control mode the processor was currently using. 


Custom Interface Boards 
to an electronics design house. 

Swadlca. the Dual Serial Transmitter (DSTJ. In a«ron a simple executive board, the ASBX. was 
build to control the interactions of the other boards with the AC-100. 

Because the graphical programming environment of SystemBuild provides such rapid software develop- 
mS ^stof the P time speht developing the MSTI 2 PIL went toward hardware development. 


Conclusion 

Rv takina maximum advantage of the AC-100 development environment, one engineer spentthreemonths, 

ssmssi 

existing code. 


By spending very little time on software development, the engineer was allowed to focus on the more diffi 
cult task of hardware development. 
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